With the floor at MediaWiki 1.43, the deprecated global-namespace
fallbacks (e.g. \Html, \Title, \Parser) can be dropped in favour of
the namespaced equivalents (MediaWiki\Html\Html,
MediaWiki\Title\Title, MediaWiki\Parser\Parser). Replace deprecated
aliases across the extension and tidy up unused / redundant use
statements in passing.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The Bootstrap 5 migration lands on top of this PR; both rely on a
modern MediaWiki and PHP. 1.39 went EOL in late 2024 and 8.0 in
November 2023, so neither floor is plausibly in use by current
deployments.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

With the floor at MediaWiki 1.43:

* the `wgVersion < 1.39` init check in `BootstrapComponents::init()`
  is unreachable; remove it
* PHPUnit 9+ ships with `assertMatchesRegularExpression()` on every
  supported version, so the `wgVersion < 1.40` branches that pick
  the deprecated `assertRegExp()` form across seven test files
  collapse to a single straight call

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

`var` was PHP 4 syntax kept around for back-compat; under PHP 5+ it
behaves identically to `public`. The four fields here are only
consumed through their accessor methods on the same class. Make
that explicit with `private`, matching the rest of the codebase.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The namespace-modernisation commit migrated the bulk of `use \X;`
imports to their unprefixed form; this is the one that was missed.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

MWException has been deprecated since MediaWiki 1.40, with the
recommendation to use native exception types or a domain-specific
subclass. Replace every existing throw, catch, expectException,
docblock, and import. The exception sites here are all
programming-error cases (invalid arguments, broken invariants),
so RuntimeException is the natural fit.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

5.2.3 shipped @deprecated markers on:

* `ModalBuilder::__construct( ..., $parserOutputHelper )`
* `ApplicationFactory::getNewModalBuilder( ..., $parserOutputHelper )`
* `OutputPageParserOutput::__construct( ..., $parserOutput, ... )`
* `OutputPageParserOutput::getParserOutput()` (and the `$parserOutput`
  field it returns)

These have been unused since the modal inline-emission fix in 5.2.3
gave both classes a path that no longer threads a ParserOutput or
ParserOutputHelper through. Drop them and update every caller and
test.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* `ParserOutputHelper::areImageModalsSuppressed()` is unreachable.
  Modal-suppression already flows through
  `BootstrapComponentsService::setModalsSuppressedByMagicWord()` (set
  in `HooksHandler::onInternalParseBeforeLinks` and read by
  `ImageModal` via the service), and no caller of
  `areImageModalsSuppressed()` remains.
* `BootstrapComponents::EXTENSION_DATA_NO_IMAGE_MODAL` was only ever
  read inside `areImageModalsSuppressed()`, so it goes with it.

The deprecated `ParserOutputHelper::addModules()` and its single
caller in `AbstractComponent::augmentParserOutput()` look orphan-
adjacent, but actually publish the vector skin's per-component
module variants (modal.vector-fix, popover.vector-fix) under a
hard-coded 'vector' key that everyone receives. Reshaping that
path would change runtime module emission; leave it alone in this
PR and clean it up separately.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The MediaWiki Linker (via RemexHtml's HTML5 serializer) stopped emitting
`alt=""` for images that lack an explicit alt text, and dropped the XHTML
self-closing slash on `<img>` somewhere between REL1_43 and REL1_44.
The four expected-output regexes in ImageModalTest and
ImageModalTriggerTest that hard-coded the XHTML form now break on
REL1_44+. Make `alt=""` and the trailing ` /` optional so the patterns
match both forms across the supported MW range.

While here, also drop the `(<span>)?` / `(</span>)?` optionality around
the `<img>` in ImageModalTest: current MW always wraps the
thumb-rendered image in the `<span>` pair.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>